Search the Community
Showing results for tags 'framework'.
Found 4 results
Node Framework Tutorial by Worthy What is Node Framework? A node based framework breaks actions into different classes. Each class extends a Node and has a validate and execute function. In this tutorial I will be writing a basic powerminer to demonstrate the effectiveness of using Nodes. ________ Node class: Validate: if true, will run the execute method. Execute: where the action happens ________ Second, we will plan and break down the actions we'll be creating. In a powerminer, there are really only a couple classes necessary: A GUI class (optional) A MineOre class A DropOre class Since this is a basic tutorial, I'm going to skip the GUI class And for simplicity's sake, I won't be externalizing any variables (I usually have separate classes for Constants and Variables). The MineOre class: ____ The DropOre class: ____ Lastly, the main class, PowerMiner: Tying everything together: When the script is initiated we add all the nodes we want into the ArrayList of nodes. The script then loops indefinitely, looping through each node in the ArrayList, validating it, and then executing. The min and max parameters I have set in the loop method, ensure the bot waits at least 20 to 40 milliseconds in between nodes. _________ As you can see you can do much much more with a node-based framework, but this tutorial shows the barebone basics. For example: if you have an AIO script, you can have the GUI determine which nodes to add to the ArrayList. You can delete nodes to run if an action is completed, etc. Full script on GitHub: https://github.com/WorthyTRiBot/PowerMiner Regards, Worthy
OSRS scripts often require setting up complex decision trees, in one form or another, in order to achieve the necessary workflow from the bot. The OOP solution to this is to create a DecisionTree class and have many DecisionNode classes, each with an ifValid() and an ifNotValid() function. However, this results in long convoluted path structures, and can result in an ungodly number of files, if the logic gets complex. The FP solution is to create a set of functions that can handle the same logic, using any() and all() methods to mimic nested if statements built with && and || statements. This seems a bit more elegant to me, and I have not seen it posted to these forums yet, so I'll leave it here. Though the code in this snippet is written in Kotlin, it can be very easily translated to Java to achieve the same effect, though the code will be less concise. Conditional (Static Class): Example Usage: Keep in mind, this is essentially the same as a bunch of nested if statements, though it has the advantage of being more concise and reading a bit clearer, imo. I challenge any of you to reproduce the above code using if, else statements and post it below. I promise, it will not be anywhere near as pretty as the code above. If someone requests, I will provide the Java equivalent. But let's be honest, Kotlin is the future
Looking at the tutorials I didn't notice anyone using a graph-based framework, so I thought that either people hadn't thought of it or at least the newer or less experience programmers weren't aware of using this, so I thought I'd share it. GraphScript is a graph based framework, using a cyclical graph to model the functionality (where each vertex would be the same as a Node or Task from other frameworks) the advantage of this, is that when doing stuff that is rotational such as a skill or simple minigame (I use Wintertodt as an example, something like Hunter would be a fantastic example as well) then it makes sense to use something that more correctly models a human's behavior. What do I mean by cyclical? Take a look at this flow chart I made for Wintertodt To breakdown what is happening in the framework, the bottom section is the overlying framework. It decides whether to bank, or go play the minigame. This area also will potentially go into the wait functionality, if the game hasn't started yet but it doesn't need to bank. The top section is a little more interesting, essentially the arrows are ways to traverse between eachother. So for example burn will never traverse back to fletch, fletch will never traverse back to chop. The advantage of this is that everything is self contained, you don't have to write code worrying about messing up the burn in the fletching class, since that'll be in its own section. For these simple cyclical things it makes everything much more self contained and easy to work with. The downside is that you have to be more careful in your coding, if it gets stuck in the chopping class for example, while it's below the door outside of the minigame, the entire script is stuck. Typically it's pretty easy to avoid this happening, it just requires a little extra thought. Here's the source code: https://github.com/Mkerian10/GraphScript I re-wrote this on my pc so and I haven't ran through it so if anyone sees any issues lmk. Of course you don't (and probably shouldn't) directly copy this framework, but rather use the ideas to implement your own.